C Code cleanup #1018
C Code cleanup #1018
Conversation
|
I was unable to run the testsuite because it have a bunch of bugs, but i won't go there in this PR because i was just going to try a hello world and end up falling in this huge cleanup. The only commit that needs review is the vm_mngr.c:dump() one. Also, it will be good to have a coding style guideline somehow, i took some assumptions like (C uses tabs and python 4 spaces, keywords have a space before (, functions don't, operators must be surounded by spaces for readability, etc.. and i tried to be consisitent with those rules here and there, there still more arch-specific code in the jitter that needs some attention because its mixing spaces and tabs for indentation. |
|
Hi @trufae ! Anyway, I am not sure about putting my name in every files, as some people contributed to the code ... |
|
From what i know when i was involved in GNU. The copyright must be done in the following way:
- LICENSE or COPYING file in the root directory containing the full license text
- each source file must start with a copyright statement which is project name, ownership, license and year range
Some comments on this:
- LGPL requires 2 COPYING files (because L is an extension to the original gpl license)
- include files cant be licensed, because those are used for interfacing and compatibility from other files or projects, so no need to put copyright there.
- email is not necessary in each file, only in root license file, or in a separate AUTHORS file, to make that info centralized, and make it less painful to update in case of changes
… On 30 Mar 2019, at 18:02, serpilliere ***@***.***> wrote:
Hi @trufae !
Thank you for the C clean. One remark:
In fact I am not ar EADS (and EADS has changed its name) so it may be something like:
Copyright (C) 2011-2019 Fabrice Desclaux
Anyway, I am not sure about putting my name in every files, as some people contributed to the code ...
In fact I am not very familiar with copyright stuffs..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
There are many conflicts and should be rebased ;) @trufae |
|
Hum. Before rebasing, we have to double check the code rules applied on the code. |
|
For the C code I recommend to setup clangformat and the check can even be added as the job in Travis, to automatically check pull requests conformity. |
|
Hum interesting! We will look at that 😄 |
No description provided.